Scene 96

home *** CD-ROM | disk | FTP | other *** search

/ Scene 96 / Scene 96 International Edition (Zyklop Software) (Disc 1) (1997).iso / emulator / amiga065 / docs / faq < prev next >

Wrap

Text File | 1996-12-20 | 16.7 KB | 283 lines

Some Frequently Asked Questions. Please read this carefully if you have problems. Q: Where can I download a Kickstart ROM/Amiga games? A: Read the docs again. You can't. It would be illegal to put a ROM image or other copyrighted software on the net (yes, even if you once bought a specific Amiga game and sold it together with the computer, downloading the same game now would still be illegal. Sorry.) Q: When will version 1.0 come out, and what will be in it? A: I have no idea. I don't give too much thought about the version numbers. The only thing I can say about them is that they increase monotonically. I also can't really say what features will be added. As many as useful, I hope. Q: Will you support CyberGFX (or some other standard) to make the Workbench run in a higher resolution? Couldn't you use ARDI's CPU emulation to speed it up? A: UAE is free software. It comes with sourcecode. ARDI's Executor, and as far as I know all the Amiga graphics card "standards" are proprietary and sold commercially. The companies that make these programs have no reason at all to give away their code for free, because they wouldn't make any more money if they did. The only option for better graphics support is to rewrite the graphics library with a native equivalent. That's a huge amount of work. (yes, I really get asked this kind of thing! I don't know where people take these ideas from). Q: Will there be any form of support for high-resolution graphics modes (e.g. Workbench in 1024x768)? A: I don't know yet. I hope so, but there are some technical difficulties. There are several options how it might be implemented: - reimplement all of the Amiga OS: Painful. No, it wouldn't suffice just to rewrite graphics.library native as I once thought naively. That wouldn't work. You'd need a native kernel (i.e. exec.library) to get it to work because graphics and esp. intuition multitask happily and that doesn't work in native emulation code yet. (There are some bits and pieces in execlib.c, and it even occasionally boots if you turn these on, so you may want to play with that if you're a programmer) - emulate graphics card hardware: _should_ be rather easy, once you get chipset documentation (maybe steal from Linux/68k, I think they have some support for graphics cards in their X server). You'd still need some form of commercial support software, i.e. a CyberGFX or EGS driver or whatever for the particular graphics card model that's emulated. Q: Is it possible to read Amiga disks with a PC? A: Ask that in comp.emulators.misc :-) The answer is: NO! Unless you invent and build some extra hardware yourself, which no one appears to have done yet. You'd also need some extra software driver; the whole setup would be similar to the X1541 cable/software for C64 emulators. Q: Couldn't I attach an Amiga floppy drive to the PC somehow, and use that to read Amiga disks? A: You can attach Amiga (low-density) drives to the PC, because they are completely identical to PC drives. This won't help you, because the problem is not the drive, but the PC floppy controller. You have to live with it. Q: But... A: No way. Q: How can I transfer non-DOS disks that are used by many demos? A: With transdisk. The fact that they are unreadable by AmigaDOS does not mean they are unreadble by transdisk. Long explanation: There are two things to consider when talking about the "format" of a disk. First, the low-level format which divides each track into sectors in a special way. Most Amiga disks are in the standard Amiga format which has 11 sectors with 512 bytes each per track, with a total of 880K per disk. There's also some extra information outside the sectors so that the floppy controller can find the sectors. PC disks use a different format, which is the reason why a PC controller can't read Amiga disks. If a disk is formatted this way, it can be copied with the normal AmigaDOS diskcopy program or the Workbench equivalent, and transdisk can handle it. Copy-protected disks have a different track layout (sometimes, they don't divide the tracks into sectors at all, or use more sectors, or put different things between the sectors. This type of thing can't be handled by diskcopy or by transdisk. Now, the second part of the "format" of a disk is the filesystem. If you want to put files and directories on a disk, you have to write some special information into some of the sectors on the disk. That information includes (for example) the name of the disk (e.g. "Workbench1.3"), and what files it contains. This information is called a "filesystem". The Amiga knows about several filesystems: There is the original filesystem (called OFS), and the newer Fast Filesystem (FFS) which was introduced with Kickstart 1.3. If you don't put a filesystem on the disk, the data in the sectors can still be read by programs like transdisk or diskcopy, but the data makes no sense to them. The point is, it doesn't have to. It only has to make sense for the Workbench which tries to determine what files there are on a disk. If the Workbench can't find a filesystem it knows about on the disk, it will be marked as a non-DOS disk. Q: How can I change diskfiles? A: Your version of UAE may have a user interface (the X11 version does) which enables you to do this. Read your system-specific README file for details. You can also use the UAE_CONTROL programs from the "amiga" subdirectory. Q: UAE does not work with my Kickstart 1.2 image. A: You may need to turn off the harddisk and fastmem emulation with the "-a" parameter. Kick 1.2 doesn't support the autoboot features that the harddisk emulation requires. Q: The "configure" script does not find Tcl/Tk, but I have it installed! A: The script checks for an executable called "wish4.0". There is currently no better test. Unfortunately, this executable is not always present, even though Tk 4.0 is installed. If that is the case, find the "wish" executable, go into the directory where you found it and type "ln -s wish wish4.0" (provided you have write rights in that directory, i.e. you are super-user). Then go back to the UAE directory, remove the file config.cache and rerun "configure". That should do the trick. Q: Is it possible to read Amiga harddisks with a PC? A: Yes. Linux 2.0 has an Amiga filesystem that can reportedly read Amiga OFS/FFS harddisks. Please don't ask for details, I didn't write the thing, and I don't use it (yet). Q: When UAE starts up, it says "Illegal instruction: 4e7b". Why? A: That's normal, it's just the Kickstart CPU type test. Q: When UAE starts up, it says "Illegal instruction: 00f8" (many times). Why? A: That's because your Kickstart ROM was compiled for the 68020. (could also happen when there's a bug in UAE) Q: When UAE loads <insert your favourite game> it says "Non-standard sync". A: Your favourite game is copy-protected. There are ways to transfer such disks, but it's complicated and I won't help you because it would be much too time-consuming to figure out all sorts of copy-protection schemes. I hope there will be a general solution some day, but for now you're unlucky. Q: While it compiles, it says "xxx illegals generated" or "16 mismatches". Is this a problem? A: No. I can use this information to tell whether there is a problem, and there isn't. Q: Why is there a blank area on the left side of the screen? A: The Amiga can display graphics there, but usually doesn't because this would disable some sprites. The area is only used by some overscan demos. Normal screens are off-center. I'm not going to do anything about that. If you can't stand it, you can try to use 320x200 or 640x480 resolution, which will attempt to center the screen. This is near impossible to get right for every program. If your screen doesn't fit in lower resolutions, use 800x600. Q: Benchmark program <insert your favourite benchmark> gives weird results. A: Amiga programs run by the emulator think the Amiga timers can be used to measure real time. But in UAE, they only measure "emulation time". Sysinfo, for example, gives the same results on all machines. So don't run benchmarks to test the emulator speed. Some benchmarks also use tight loops of DIV or MUL instructions to measure CPU speed, and in "emulation time" these instructions take as much time as any other instructions, and you'll get much too high values. Q: Wasn't this called the Unusable Amiga Emulator? A: Yes. But no one thought the name was very fitting anymore, though. It was only really appropriate for v0.1, which couldn't even boot. Q: Sometimes, after UAE exits, there is no autorepeat for the keys! A: Do "xset r on" (happens only in X, apparently mainly on Solaris boxes. Dunno why.). [Should be fixed by now. Note that this always happens when UAE crashes] Q: Would it be possible to speed it up by emulating the CPU native on, say, a 68k Mac? A: I doubt it. UAE needs to be able to interrupt the CPU emulation anytime to perform tasks necessary for emulating the hardware. So you can't just let it run all by itself. Q: Would it be possible to speed it up by using graphics accelerator boards for example by using the blitter in S3 chips? A: I doubt it. I'm no PC graphics card expert, but probably the only thing the S3 blitter and the Amiga blitter have in common are seven lowercase letters. Even if they were similar you'd have to keep all Amiga chip RAM in the graphics memory and that would most likely make everything painfully slow. Q: How about adding special support for the GUS that uses hardware features to speed up the sound emulation? A: Again, due to the differences in Amiga and PC (in this case: GUS) hardware, this isn't really feasible. You _might_ get something like this to work in some special cases (ProTracker modules might be a case that could be made to work), but I don't think you can come up with something that emulates all of the Amiga sound hardware. The problem is that by just examining the values a program writes into the audio hardware registers, you can hardly figure out what a program is trying to do, and what it is going to do in the future. In contrast to that, it's easy to write a SoundTracker module player for GUS cards because you know exactly what you are playing, and how you have to do it. (That doesn't mean you can't use the GUS for sound output; you just can't use it to _speed up_ the sound output) Q: Emulating all the hardware is a bad idea. Why don't you just emulate the OS? After all, that's what makes the Amiga the Amiga. A: Short answer: I disagree. Long answer: The OS is half of what makes the Amiga the Amiga. It is a very nice OS, and there are some features that I miss in any other OS, but it is also severely lacking in terms of (for example) memory protection and filesystem performance. The other thing that made the Amiga special back in the 1980s is the custom chip architecture. If you look into old (1985) computer magazines, you will find that the capabilites of the Amiga OS are only mentioned as a side note, because people were not aware that it was revolutionary for a home computer. They were aware, though, that the Amiga could display 4096 colors at the same time and that it had a blitter and a copper that could do all sorts of stuff, like bouncing balls for instance. And I think it was the superiority of the hardware that made the Amiga a success. I see UAE as a program that is similar to C64 emulators: it allows you to run some old games and other programs that you can't replace with better equivalents on the PC. As such, it can already be used to run non-action games (like Monkey Island or Bard's Tale) at a satisfactory speed. Faster CPUs will eventually make it possible to run action games, just like faster CPUs have made it possible to emulate a C64 at full speed on a PC. UAE is not (primarily) meant for the Amiga PowerUser who is running high quality applications on his A4000 with a 68060 board, but for people like me who switched from an A500 to the PC a few years ago because they wanted to make money by developing software. Besides, emulating an OS is far more difficult IMHO. Especially if the platform you are emulating it on is completely different than the platform that is being emulated. You'd have to mess with endianness conversions and other nightmares. The AmigaOS wasn't designed with portability in mind either. Q: How fast is it? A: This is the most difficult question to answer. The easy way to answer is "It depends", but I'll try to do better. All timings I give here were measured on my machine, a P90, using SVGAlib, with the FASTER_CPU and DONT_WANT_SOUND options. Note that different versions of UAE generally run at different speeds, so take these timings with a grain of salt. The MC68000 emulation is more than twice as fast as a real A500. I measured this by letting PowerPacker try to compress itself (it already was compressed). It took UAE about 6 minutes, my A500 took about 15. You can get about twice the speed of an A500 for this type of program (not much graphics activity) or if you set the frame skip rate to a high value. For games and demos, the CPU speed does not matter, but the average frame time is important. UAE can calculate this automatically. The SVGAlib version gives the number when you exit the emulator, to obtain the value with the X version you need to interrupt it and type "c" in the debugger. A real A500 has a constant frame time of 20ms (50 Hz). If you have a game/demo that has lots of blitter activity, many copper/ sprite effects, dual playfields and scrolling, no one can help you. Fortunately, this case is extremely rare. Normal games that have a number of blitter objects, scrolling and maybe some sprites run at 1/3-1/4 the speed of an A500 in the worst case, some run at 1/2 the speed. Lowering the frame rate helps enormously here, and at 1/5 frame rate, about everything runs somewhere between 50% and 100% the speed of an A500. This still isn't the full story (I bet you start to see why the question is hard to answer). A real A500 without fast memory gets slowed down to about half its speed in Hires 16 color mode. More bitplanes also slow UAE down, but not quite as much, so it can be several times faster than an A500 in that mode. Finally, some remarks about the m68k->i386 code compiler that is available in the Linux version of UAE. It shouldn't be used for games, it will completely kill your frame rate. It's possible to use it for Workbench applications, though, and the frame rate shouldn't be a problem in this case. I measured PowerPacker the same way as described above, and the time when using the compiler is slightly above 1 minute (10-15 times an A500). With the USER_PROGRAMS_BEHAVE option, it's as low as 40 seconds. I've also run the BeachBall benchmark from AIBB 6.5. This takes around 10 minutes on an A500, UAE is 3 times faster with the compiler. For some benchmarks that use function calls heavily, the compiler isn't a win (although the current version should no longer be slower like previous ones). I have little "real world" data, please let me know if you made any experiences with the compiler. Q: How can I make it faster? A: Run the emulator in the lowest screen mode (320x200), set it to 256 colors, make sure aspect correction is disabled, and set the frame rate to every 3rd frame. Finally, disable sound (if you have a version that lets you compile your own executable, set "DONT_WANT_SOUND" in config.h). It won't look very nice, but it will run as fast as your machine allows. Q: What do I do if a game/demo/application doesn't work? A: If you're trying to run a game or a demo, enable some SLOW RAM, and try running it again. Some older software has compatability problems which SLOW RAM can sometimes fix. If it's an application, check for obvious things like Kickstart version requirements, RAM, etc. Also make sure the software you're trying to run isn't for AGA equipped machines. Q: Will there be a Windows version? A: Several people have mailed me in the past that they had started porting UAE to WinNT/Win95. I never heard from most of them again. I assume they found out that Windows sucks hard.